Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 090 / cscv.arc / CSVS.DOC < prev next >

Wrap

Text File | 1987-04-20 | 28.0 KB | 521 lines

The Computer Shopper PC Clone Validation Test By Andrew M. Fried & Kenneth McMillen Introduction ------------ There has never been a better time to purchase an IBM clone microcomputer than today. Overseas production and fierce competition have made the computer consumer master of the industry. There is generally one question facing most prospective buyers of clone computers, and that is whether or not the system is, in fact, a true compatible. Beginning next month, Comupter Shopper will add another program to its list of programs used to test a systems compatibility with that of the PC. This program, called BIOSTEST, invokes almost all of the ROM BIOS calls and checks them for proper operation. The purpose of this article is to discuss the various interrupts available in ROM BIOS and how they can be checked for compatiblity. Interrupt 5 - Print Screen -------------------------- When the combination of the Shift-PrtScr keys are simultaneously depressed, the ROM BIOS generates an interrupt type 5. This interrupt causes the contents of the screen to be sent to LPT1:. Our test of this interrupt is simple and straightforward. To begin with, a ROM BIOS call is made to determine the current video mode. Once the video mode is known, the active screen memory is known. The contents of the current screen are saved into a buffer so that they may be restored upon completion of the test. In order to insure that there is, in fact, something on the screen to print, a series of printable ASCII characters are generated and displayed onto the active screen. These characters are printed sequentially from chr(32) up to chr(127). BIOSTEST then generates an Interrupt 5. It becomes the responsibility of ROM BIOS to transfer everything on the screen onto the printer. Once the interrupt has finished, BIOSTEST restores the screen to its original condition and waits for you to press a key to continue. In order to determine whether or not the interrupt functioned properly, you must examine the printer output to see if the pattern appears correct. Interrupt 10 - Video I/O ------------------------ ROM-BIOS has a set of routines which handle various video functions. These routines set screen modes, move and find the cursor's position, select active graphic pages, up/down scrolling, read/write characters with attributes, read/write dots, and color selections. Some of them are practical if program speed is not a problem. However if you wish to do some fancy graphics that are quick then using these routines are not for you. Their performance is slow as you will see with the dot testing. The nicer functions are the screen scrolling and active page selection. To take advantage of the graphics you will need a color monitor. Before the test begins it checks to see what type of monitor you are using. If you are using a monochrome monitor the program will only do the tests which apply to a monochrome display. There are sixteen functions with this interrupt. The test will step through each one and ask you to press any key at the end of each test to continue on to the next one. Some of the tests will display a pass or fail message while the rest of them require you to look at the screen to verify certain conditions. Each of the tests will have a header at the top of the screen to let you know what is being tested. The first test that is tried is the verification of a table in ROM-BIOS that contains video initialization parameters. When you boot your system or power it on the built in diagnostics look at the switch settings for the monitor type and set up the video card with the correct parameters from this table. If one of the parameters do not match then the test fails. This table needs to match 100% if you system is to be compatible. The next test deals with setting screen modes. If you are using a monochrome display then there is only one mode. For the color display there are seven different modes. You should see each of the seven modes set (40x25 BW, 40x25 color, 80x25 BW, 80x25 color, 320x200 color, 320x200 BW, and 640x200 BW). Using this next function you can set up your cursor type. In the monochrome mode your cursor is made up of thirteen lines whereas in the color mode you have just seven. If you use this function it needs the starting and ending line. This test should display a solid cursor, starting at cursor line zero and ending at seven or thirteen. The next two tests position and read the cursor's location. The first test positions the cursor at row four, column twelve and prints the letter 'X'. You need to verify this by looking at the screen. The other test does the same thing and then reads the location of the cursor which should be at row four, column thirteen. On the screen you should see the blinking cursor at this position. Press any key when you have finished with each test. Function number four of this interrupt reads the position of a light pen. This test was not included since most everyone does not have a light pen. Function number five selects the active page to display. To fully utilize all of the memory on the video card IBM included this function which gives you multiple pages of text. In a 40x25 screen mode you have a total of eight pages of text that you could flip through if your application takes advantage of this. In an 80x25 mode you get just four since you are using twice as much video memory. This function works only with color displays. The test will first use the 80x25 mode and fill up all four pages with the page number. Then the test will ask you to press any key to flip through the four pages verifying that each screen page is filled with the proper page number. If so then this test passes. The next two tests test the scrolling functions. The first one fills the screen with text and scrolls up a window of text. The second on does the same except it scrolls down a window of text. If you see this happen then both of these tests pass. You can also see what the character set will look like. The next three tests deal with the character handling routines. The first will display a test pattern made up of all the attribute capabilites (underline, color, blinking...). The test will read the pattern from the screen and if it matches the test passes. The next test writes the test pattern on the screen and then it is read back to verify that the pattern matches. If so then this test passes. The third test also writes the test pattern to the screen but without any of the attributes so what you should see is text displayed normally. A trade off with the attributes is that you have the underline capability only with the monochrome and color only with the color display. Functions eleven, twelve, and thirteen are used for graphics. Function eleven sets the color palette. The test should cycle through sixteen colors. You will need to verify this. Function twelve handles writing dots or pixels to the screen at a particular row and column. The test should draw a box on the screen. To verify that the test did this it will read back all the dots which make up the box, please be patient while the test does this. If they are all read back successfully then the test passes. Function thirteen handles reading the color of a dot at some position. This test should draw a different box and if the test reads back each dot that the box is made up of then the test passes. Function fourteen handles writing characters to the screen and is similar to the functions describe above which handle characters. This test uses the same test pattern as used in the above test. If the test pattern is read back correctly then the test passes. The last test of the video I/O tests the current video state. Since it gets its results from a reserved area in memory, for storing system information, this is where the test was performed. Most applications use this data area to get system parameters. If this area is not identical and maintained to that of an IBM machine then compatability might prove to be a problem. This test first saves the current values and replaces them with test values. The function is executed to see if it returns the test values and if it does then the test passes. When the test finishes, it will restore the current values. Interrupt 11 - Equipment Determination -------------------------------------- There are some software packages that can determine the type of equipment your system is using. One of the most obvious reasons for this is that a program which displays graphics will not work so well if your monitor is monochrome. So the program will look to see what type of monitor you are using and execute it's code to handle a monochrome monitor. That way if the program is not dependent on using graphics, it will still operate. When you turn on your PC, a set of built in diagnostics are run to quickly test the condition of your system. The diagnostics must know what to test. It reads the switch settings you set on the motherboard for the type of monitor, amount of memory, etc. and stores those settings in a system data area. If your program requires this information then you would execute an interrupt 11. This interrupt reads the settings from the data area rather than from the actual switch settings on the motherboard. Since most programs will extract the switch settings from the system data area, this is where the test was performed. The test first of all saves the current switch settings stored in the system data area. It then replaces this value with a test value. An interrupt 11 is executed to find out if it returned the test value. If so, then the test passes. After the test has finished, the current switch settings value is restored back to the system data area. You could actually fool your system by changing the switch settings value in this data area. Interrupt 11 returns the switch setting value in the AX register. Each of the bits in this register indicate the following: bit 0 - indicates diskette drives on the system bit 1 - not used bit 3,2 - planar ram size (00 = 16K, 01 = 32K, 10 = 48K, 11 = 64K) bit 5,4 - initial video mode 00 = unused 01 = 40 x 25 black/white using a color card 10 = 80 x 25 black/white using a color card 11 = 80 x 25 black/white using a monochrome card bit 7,6 - number of diskette drives if bit 0 set (00 = 1, 01 = 2, 10 = 3, 11 = 4) bit 8 - not used bit 11,10,9 - number of RS-232 ports bit 12 - game input/output port installed bit 13 - not used bit 15,14 - number of printer ports (00 = 1, 01 = 2, 10 = 3, 11 = 4) Interrupt 12 - Memory Size Determination ---------------------------------------- When you purchase a software program, it usually will state in the documentation the amount of memory the program requires to run successfully. If you have tried running a program which requires more memory than you have available then you might get the message "INSUFFICIENT MEMORY". The program most likely has used interrupt 12 to first look at the amount of memory your system has available before trying to load the main program. This will avoid the possibility of crashing your system and leaving you in frustration as to what went wrong. The memory size is determined when your system is powered on or when your system is booted up. In the system data area there is a place which keeps the amount of memory your system has installed. This determination is stored there. When an interrupt 12 is executed, it reads this value. What the interrupt returns is the number of contiguous 1K blocks of memory. The test saves the current memory size and replaces it with a test value. Then an interrupt 12 is executed to see if it returns the test value. If the test value is returned then the test has passed. After the test is complete the current memory size is restored. Interrupt 13 - Diskette Drive Interface --------------------------------------- The low level software interface between your diskette drive and system memory is the ROM-BIOS interrupt 13. It handles the most basic operation of moving data between your program and the diskette. This interrupt is made up of six basic functions (reset the drive, getting the status of the drive's operation, reading data, writing data, verifying data, and formatting the diskette). DOS is very much dependent upon this interrupt. Since DOS depends on this interrupt to function properly you can do some of your own testing by loading and executing a program, writing data to the diskette, and formatting a diskette. This will cover all six of the functions listed above. If you can perform these type of functions, without errors being generated, then you have successfully tested this interrupt and know whether compatibility is a problem. You would also want to try and use a program off of a diskette that was formatted and setup on an IBM-PC or known compatible system. The interrupt 13 test consists of first placing a formatted, double sided diskette into drive A with, better yet, some information stored on it. Since a majority of the diskette drives around now are double sided, this test will test both sides of the diskette only. Once the diskette is in place then press any key to continue. The test begins by reseting the drive. Then it does a series of read/write tests and gets the drive's status for both sides of the disk, on all forty tracks. If an error occurs, then an error message will be displayed indicating the type of failure. The error messages are based on the error codes listed in ROM-BIOS. If one of the tests fail they are retried two more times to verify the error. DOS does a better job of determining errors since that is what it was designed to do. You may then proceed with the testing of the remaining tracks by pressing any key. After all forty tracks have been tested then the next test, verification of data, is executed. To exercise the movement of the heads also , the test begins on the outside track, track zero, then moves to the inside, back out, back in, until the center track is reached and tested. Errors are handled in the same way as the previous read/write tests. Displayed on the screen, while the test is running, is a status line which shows you the drive being tested, the current track, the head or side, the starting sector and the number of sectors involved in the test. This test is performed on drive A, drive zero, only and works with an entire track, nine sectors, at a time. When the verify test is running you can watch the drives head movement by looking at the current track it is on. After the test has finished you will see the test pass or fail message. If just one error occurs then the whole test is considered a failure. Interrupt 14 - Async Communications ----------------------------------- While the ROM BIOS provides support for the serial ports, most programmers requiring the use of these ports routinely bypass BIOS and work directly with the hardware. This is due to the fact that BIOS support for these ports is minimal, at best. The ROM BIOS specifically provides four support services to the asynchronous ports:initialize port, send a character from port, receive a character from port and return status of com port. Most communications programs will utilize only service 0 (initialize port) since interrupt driven routines, which are not directly supported under BIOS, are the preferred method of handling incoming data. For this reason, this test will run through diagnostics of service 0 only. Various baud rates are initialized using BIOS. This diagnostic then goes into the UART chip itself to ascertain that the correct timing parameters were sent from BIOS. This test will display the various baud rates set along with the number which was found in the divisor latch. If they correspond with the correct value, the test will pass. This test will only be performed on COM 1. Interrupt 16 - Keyboard ----------------------- There are actually two different interrupts used to support the keyboard. One interrupt (interrupt 9) is used primarily for low level support of the serial transmissions from the keyboard. This interrupt is not generally invoked by user written software. The other keyboard interrupt, which is often referred to as the "read keyboard support", is interrupt 16. This is the keyboard interrupt accessed by most user software programs. As you could imagine, interrupt 16 could not function properly if interrupt 9 failed to perform its duties. For this reason, BIOSTEST concerned itself with interrupt 16. Interrupt 9 is not directly tested by the validation program. Under interrupt type 16 there are three services available. Service 0 reads the next character entered into the keyboard and returns the code and its scan code in the CPU registers. Service 1 is invoked simply to tell us whether or not a key has been entered and is waiting in the keyboard buffer for processing. Finally, service 2 returns the status of the shift keys. In order to test these services, information was placed into the ROM BIOS data area. Since the interrupt itself uses the data area to store information from the keyboard, simple memory manipulations are performed which trick the keyboard into thinking that keys were pressed which, in reality, weren't. This enables us to check the ROM BIOS without addressing the physical keyboard itself. For example, by adding a character into the keyboard buffer and changing one simple pointer, the BIOS thinks that a key is waiting to be processed. When service 0 is subsequently called, it should return indicating a character is waiting. Interrupt 17 - Parallel Printer Port ------------------------------------ Just as in the case with the serial port, the parallel port is supported by ROM BIOS even though the device itself is not part of the motherboard. This means that the system may support a device that is not even attached to the system. This interrupt contains three separate service routines. Service 0 sends characters out the port one at a time to the printer. Service 1 is used to intialize the printer port and service 2 returns the printer status. BIOSTEST primarily invokes these routines. It is up to the operator to determine whether or not the hardware is responding correctly. For example, under service 0 a test pattern of printable characters is sent out the parallel port using interrupt 17. To ascertain the correctness of the call, it is necessary to visually examine the output. Service 1 merely initializes the port. The only testing performed on this service is to examine the return code for inconsistencies after the call is made. Service 2, which returns the printer status, is easily verified by performing such tricks as taking the printer offline and then invoking the test. If working properly, BIOSTEST will indicate the condition to you. Interrupt 18 - Invoke ROM-BASIC ------------------------------- If you don't have a fixed disk attached to your system, chances are at some time or another you booted up your system without a disk in the drive. The result was that the machine finally enters ROM-BASIC. Entry into this firmware version of Basic is made possible by interrupt 18. I do not know of any clone that has Basic installed in ROM. Microsoft wrote a generic Basic language for clones which emulates IBM's ROM-BASIC however it is a software only version of the language. I'm referring to GWBASIC, of course. For completness, however, BIOSTEST includes this test. When this test is performed, an interrupt 18 is invoked which, on an IBM, should call up the ROM resident version of Basic. Do not expect this test to perform correctly on clones. It is even quite possible that the machine may totally hose up when this call is made. Interrupt 19 - Boot Strap Loader -------------------------------- As soon as the computer is turned on, ROM BIOS begins initializing the data area and performing diagnostic tests. At the conclusion of these tests, control is turned over to the boot strap loader via interrupt 19. This routine will simple invoke the interrupt 19 code. When this happens, your computer should simple perform a complete reboot as would occur had you just turned your system on. Interestingly enough, not all systems seem to respond this interrupt the same. In particular, hard disk based systems will sometimes 'hang' when this test is performed. In general, however, if your system comes up from a power off condition, the system should be considered ok. This test is optional and not a true gage of compatibility. It was included in BIOSTEST for the sake of completness. Interrupt 1A - Time of Day -------------------------- Around 6:30 every morning, we all feel as though our lives are controlled by a clock. Well, we have at least one thing in common with a computer! In the case of the PC, the second hand of the clock is advanced approximately 18.2 times every second. For you techies out there, the strange timing interval is the result of a 1.2 mHz clock divided with a counter by 65536. At each advance, a register is incremented. Determining the actual time is therefor a matter of transforming this count into something more meaningful by us mortals. ROM BIOS doesn't give us the upper level support to do this; a service request under DOS interrupt 21 does, however. What ROM BIOS does give us, however, is the ability to read the so-called clock and to set the clock. These facilities fall under interrupt 1A services 0 and 1 respectively. This test will read the hardware registers and then perform a bios call to read the registers. If they are identical, the test passes. The second test performs just the opposite; a new value is set into the clock. Once done, the hardware is examined to see if the call was successful. Should the registers differ, a failure warning will be issued. Printout of ROM BIOS Data Area ------------------------------ ROM BIOS is contained on non-volatile memory. As such, it does not change, it need not be reloaded every time the system is powered up an can operate much faster than the volatile memory chips affectionately referred to as RAM. This is all well and good, but in order to operate certain variables that are used by ROM BIOS must be able to change. To accomodate this, a certain area of RAM memory was set aside specifically for ROM BIOS support. This area is called the ROM BIOS data area. There is a wealth of information stored within these areas. As a matter of fact, it is very common for software packages to examine certain locations within this area for information pertinent to the operation of the program. If you were to examine a technical manual which lists the actual ROM BIOS (such as the IBM Technical Reference Manual), each variable in this area has been assigned a label. This procedure produces a hardcopy listing of all of the data located within this data area and displays it along with its actual name as it appears within the tech manual. This utility is very useful for comparing certain values contained within the data area from those of the real thing. In order to get the printout, however, a printer must be attaced to your system. The Romdate Utility ------------------- Hidden deep within the recesses of most ROM BIOS are three fields of information which you might find of interest. These fields include the type computer system, the date of the ROM BIOS and the copyright notice. The field containing the type of computer is important since many machine specific programs examine that memory location in order to determine the host computers configuration. Rather than return a meaningless code, BIOSTEST returns the type system identified by the system code. Another location within the ROM BIOS has historically been used to provide a date stamp for the ROM BIOS itself. BIOSTEST will display this date. Finally, a third location yields an ASCII string which consists of a copyright notice. This is really quite interesting (and important, as well). There are some software packages that specifically test this area in order to find the three magic characters "IBM". This was supposedly done to prevent certain software from running on clones. In order to maintain compatibility, software houses producing ROM BIOS decided to install their own copyright notice which also contains the magical letters. Some are quite humorous and may range from "IBM compatible" to "This is not an IBM...". This utility will print the first 60 or so ASCII characters found in the area traditionally reserved for such purposes. The Romcheck Utility -------------------- ROM BIOS is actually nothing more than a collection of software procedures which have been stored inside the computer non-volatile memory. Software of this nature is referred to as "firmware". Many systems contain other devices not directly supported by either the ROM BIOS or DOS. Two such examples that are most common are the fixed disk extension to interrupt 13 and the Enhanced Graphics Adapter extension to interrupt 10. In order to provide support for these devices, the cards themselves contain either ROMS or EPROMS containing the firmware necessary to support that device. During a power on self test, the ROM BIOS tests certain areas of memory for these ROMS and, if located, pass control to these programs. The programs, in turn, create the necessary hooks into the operating system which enable the device to function. This utility will scan the computers memory from C000:0000 up to F400:0000 in search of these ROMS. Should a ROM be found, its address will be displayed on the screen. The most common ROM will be found at address C800:0000. This ROM provides support for the fixed disk. EGA cards, on the other hand, will generally be found at C000:0000. Conclusion ---------- The program BIOSTEST is an attempt on our part to provide a standard and meaningful test to ascertain a PC clones compatibility to its predecessor, the IBM PC. In developing our test, we tried to simulate, wherever possible, actual situations where the ROM BIOS would or could be invoked. Our tests are simple yet quite through. There is, of course, the possibility that an unknown bug or glitch in the ROM BIOS could go undetected by BIOSTEST. To remove this possibility would require programming effort in excess of that used to originally develope the BIOS itself! Quite frankly, there are few systems in the market today whose ROM BIOS is not compatible. Our program will help to identify the small minority of systems containing a flawed ROM BIOS.